insightwatchのセキュリティチェックでオールグリーンを目指す（その1: CISベンチマーク IAM設定編）

insightwatchを使ってみた

#セキュリティ

#CISベンチマーク

#AWS IAM

#AWS

江口佳記

2019.07.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

オペレーション部　江口です。

当社が提供するサービスであるinsightwatchでは、自分のAWS環境についてCISベンチマークやAWSセキュリティチェックリスト、IAMベストプラクティスといった規準でチェックを行うことができます。チェックを全てパスすれば、非常に堅牢にAWSを運用することができますが、しかしながら全てのチェックを全てパスし、オールグリーンにするのはなかなか難しいようです。

実際のユーザ様への参考の意味も兼ねて、身をもって自分の個人検証用のAWS環境でオールグリーンを目指し、その過程をブログで公開していこうと思います。

今回の記事では、CISベンチマーク(CIS Amazon Web Service Foundations Banchmark v1.2)の「1 Identity and Access Management」の指摘事項をすべて解消するところまで紹介します。

参考情報

「insightwatchとはなんぞや？」や「どうチェックするのか？」「CISベンチマークって何？」という方のためにいかに各種情報へのリンクを挙げておきます。ご参考くださいませ。

insightwatch:
- https://insightwatch.io
insightwatchへの新規の登録やチェックの実行の仕方の解説：
- https://dev.classmethod.jp/cloud/aws/insightwatch-start/
CISベンチマークについての解説：
- https://dev.classmethod.jp/cloud/aws/reading-cis-aws-foundation-benchmark/

最初のチェック結果

さて、とりあえず私の個人検証環境をinsightwatchでチェックしてみた最初の結果は下記の通りです。

注意12個、重要45個の指摘があります。結構てんこ盛りですね・・・入社して1ヶ月にも満たないまだ私の検証環境にはそれほどAWSリソースはないのですが。

このうち「CIS 1. Identity and Access Management」のチェック結果の詳細は以下の通りです。

ちなみに「マネージド」という項目がありますが、これは当社サービス「クラスメソッドメンバーズ」をご契約されている際、当社で管理している項目について表示されます。rootアカウントなどを当社で管理しているので、それらについてはユーザ様は対応をする必要がありません。私のアカウントもクラスメソッドメンバーズで管理されていますので、対象項目は同様に「マネージド」となっています。

それでは個々の項目を潰していきます。

各IAMパスワードポリシー(CIS 1.5 - 1.11)

1.5から1.11はいずれもIAMパスワードポリシーのチェック項目となります。まとめると「大文字・小文字・記号・数字必須で最低14文字、パスワードの再利用を24世代まで禁止、パスワード有効期限が90日以内」というポリシーとなります。

GUIであればIAMコンソール -「アカウント設定」から各項目を変更します。またAWS CLIで各ポリシーを一気に流し込むこともできます。

aws iam update-account-password-policy \
         --minimum-password-length 14 \
         --max-password-age 90 \
         --password-reuse-prevention 24 \
         --require-symbols \
         --require-numbers \
         --require-uppercase-characters \
         --require-lowercase-characters \
         --allow-users-to-change-password

一番後ろのパラメータ「--allow-users-to-change-password」は、ユーザにパスワード変更の許可を求めるというオプションで、上記の要件には上がっていないのですが、IAMベストプラクティスに含まれているのでついでに設定しています。 CLIで設定した場合の確認のコマンドは下記です。

aws iam get-account-password-policy

GUIでは下記のようになっていればOKです。

私の環境では1.9-1.11が引っかかっていましたが、上記対応ですべてクリアです。

CIS 1.16 IAMポリシーがグループまたはロールにのみ適用されていること

この要件はIAMポリシーにユーザに直接アタッチしていると引っかかります。ユーザがそれぞれポリシーをアタッチしていると管理上複雑となるので、必要なポリシーを持つグループを作り、そのグループにユーザをアタッチしたほうが良い、というわけです。

私の環境の場合、CodeCommit用に作ったgituserというユーザに直接ポリシーをアタッチしていました。推奨に従って、同じポリシーを持つ新しいグループを作ってそれをアタッチする形に変更しました。

手順は下記の通りです。

IAMコンソール -「ユーザ」で、一覧から各ユーザをクリック。「アクセス権限」タブのポリシー情報で、直接アタッチ済みのポリシーを確認
IAMコンソール -「グループ」で新しくグループを作成し、1で確認したポリシーをアタッチ
再びユーザの設定画面に戻り、「アクセス権限」タブでユーザに直接アタッチしていたポリシーをデタッチ（ポリシー情報の右の「x」をクリック）
「グループ」タブに移動し、「ユーザをグループに追加」を押して、新規に作成したグループをユーザにアタッチ

CIS 1.19 EC2でのAWSリソースへのAPIアクセスはIAMインスタンスロールを利用していること

これはIAMロールが設定されていないEC2が存在すると引っかかります。 AWSリソースにEC2でアクセスする場合、IAMロールを使わない場合はアクセスキーを使用する事になるので、それは止めてIAMロールを使った方が安全ですよ、ということですね。確かに1台IAMロールを設定していないEC2インスタンスがあったのですが、これは実際他のAWSリソースにアクセスしないEC2で別にアクセスキーも使っていないので問題にはならないのでは・・・と思わないではないです。

実際はこれはCISベンチマークではLevel2、すなわち「環境により設定が必要」と分類されるもので、チェックの結果も「重要」ではなく「注意」となっています。ですので必ずしも対応する必要があるわけではありません。ただ、今回はオールグリーンにするのが目的なので、一応IAMロールを設定しておくことにします。

とはいえ他のAWSリソースには接続しないインスタンスなので、どこかしらにアクセスを許可するロールをアタッチするのは避けたいところです。ということで、全てのアクセスを拒否するポリシー「AWS Deny All」をアタッチしたIAMロールを作成し、これを設定しました。Deny Allとか設定すると通信もできなくならないかとちょっと心配しましたが、SSH接続に支障はありませんでした。

CIS 1.21 不要なアクセスキーの発行を避ける

使っていないアクセスキーがあれば削除したほうがいい、ということです。無効化しただけでは駄目なようで（試した）、削除しないと引っかかるようです。確認してみると前掲のユーザ「gituser」で利用していないアクセスキーが確かにあったので削除対応しました。

CIS 1.22 制限なしのアクセス許可を指定したIAMポリシーを利用しない

フルに全てのリソースにアクセスできるAdmin権限（マネージドポリシーで言うとAdministratorAccess）を使わない、ということですね。当社では、各自の検証環境へは一旦社内AWS基幹のアカウントでログイン、その後スイッチロールして検証環境に入るルールで、この際のロールにAdministratorAccessポリシーがアタッチされています。

※スイッチロール/クロスアカウントアクセスについては以下の記事をご参照ください: